Command-line interfaces (CLIs) are a common means for enabling human-machine interaction and are particularly useful for issuing instructions to computers or similar machines.
With CLIs, a sequence of commands may be executed in a safe and repeatable way. All commands are written in a script and may be fully tested. All storage-specific scripts may be included in the classical application scripts and be executed automatically from servers.
CLIs are generally easier to use if a user can remember or easily find the commands and options, which generally is the case if they are frequently used or when full documentation is available. To facilitate generation of CLI commands, a front end GUI may be created so that a user may select commands and may flag options via a menu in order to generate one or more clean commands. Without a front end GUI, syntax errors or other errors are more likely.
A classical CLI command consists of the following components, arranged in the following order:
command name;
command flags and flag parameters; and
one or more command parameters, each followed by any required sub parameters.
Flags modify the command. They provide additional information that directs the CLI to perform the command task in a specific way. For example, the -v flag tells the CLI to display the command results in verbose mode. Some flags may be used with every CLI command. Others are specific to a particular command and are invalid when used with other commands. Flags are preceded by a hyphen (-) and may be followed immediately by a space and a flag parameter.
Flag parameters provide information required to implement the command modification that is specified by a flag. For example, the -user flag requires a user_name parameter, and the -passwd flag requires a password parameter. Flag parameters are variables; their values change to meet specific needs. Not all flags require parameters. In such case, the flag itself provides all of the necessary information. Some flag parameters are optional. Moreover, some flag parameters may allow the use of multiple values. Such multiple values must be separated with a comma, with no white space between the values.
The following is an example demonstrating the use of flag parameters:                chsession -dev IBM.2107-75L3221 -lss 50 -action add -volume 2000,5000,5001 FB        
In the example, the flag -volume is using multiple flag parameters, which are the comma-separated 2000,5000,5001.
A command parameter provides basic information necessary to perform the command task.
The following is an example demonstrating the use of command parameters:                mkpprcpath -wait yes -dev IBM.2107-75L3221 -remotewwnn 5005076303FFC0B7 -remotedev IBM.2107-7506551 -srclss 50 -tgtlss 80 -consistgrp I000:I010 I010:I011        
In the example, mkpprcpath is the command name; -wait, -dev, -remotewwnn, -remotedev, -srclss, -tgtlss, and -consistgrp are command flags; and yes and no are the only valid flag parameters for the -wait flag. IBM.2107-75L3221 is the flag parameter for the -dev flag. The -consistgrp flag does not have a corresponding flag parameter. I000:I010 I010:I011 is a list of command parameters without flags.
These flags and parameters are not straightforward, and thus many errors may arise if the command is built manually. The objective of the various embodiments described herein is to reduce such errors by providing a structured file and a program parsing such file so that a GUI generating commands, flags, and parameters may be built.
For example, all of the well-known disk bays and related software listed in Table 1 use CLI commands to configure and monitor storage for servers.
TABLE 1Storage UnitCLI nameWebsiteESSESSCLIhttp://www.redbooks.ibm.com/abstracts/sg245420.htmlDS4000SMclihttp://www.redbooks.ibm.com/abstracts/sg247010.html?OpenDS6000DS CLIhttp://www.1.ibm.com/support/docview.wss?uid=ssg1S7001162&aid=1DS8000DS CLIhttp://www.1.ibm.com/support/docview.wss?uid=ssg1S7001162&aid=1TPCTPCTOOLhttp://publib.boulder.ibm.com/infocenter/tivihelp/v4r1/index.jsp?topic=/com.ibm.itpc.doc/fqz0_tpccli3123.htmTSMdsmchttp://submit.boulder.ibm.com/tividd/td/TSMC/GC32-0789-03/fr_FR/HTML/ans5000009.htm#HDRCOMLINESVCsvcinfohttp://www.03.ibm.com/servers/storage/software/visualization/svc/index.htmlsvctaskBrocadeCLIhttp://www.128.ibm.com/developerworks/tivoli/library/t-switchts/index.htmlswitchCisco switchSAN-OShttp://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/fun_c/fcprt1/fcui.htmCLIMcDataCLIhttp://www.mcdata.com/partners/openready/develop/OPENInterfaces.htmlswitch
However, each CLI is different, using commands and flags in many ways to accomplish the common tasks of creating volumes and assigning such volumes to servers. Thus, according to known implementations, each time one decides to use a new storage box, it is necessary to learn and use a new language.
In certain cases, a front end GUI (i.e., graphical front end) is available to offer a graphical interface to the underlying CLI. Examples include easy_dscli (Front End GUI for DS8000/DS6000 DS CLI) or Scripting Tools for SAN Volume Controller.
In the IT industry generally, front end GUIs are available for some command line programs. An example is kdesu, which is a graphical front end for the su (i.e., substitute user) command in UNIX. Likewise, kcron is a graphical front end to cron, which is a command line program used to schedule tasks. Perhaps the most famous tool is the System Management Interface Tool (SMIT) for Advanced Interactive executive (AIX) administration (AIX is a series of operating systems developed by IBM).
While front end GUIs offer certain advantages in terms of usability, they are also associated with certain problems. One problem with front end GUIs is that they frequently lack the versatility and fine-grained control of their underlying command line programs. Specifically, they have limited options for modifying the behavior of commands and cannot be combined with other commands using pipes (pipes allow commands to perform highly specialized tasks that otherwise would be very difficult to perform). Moreover, front end GUIs generally attempt to hide the finally executed CLI command, and as a result the end user is unable to reuse the same action in autonomous scripts. Another drawback is that a front end GUI must be completely redesigned and recreated for each CLI, and a classical end user generally will not have the capability of adding new commands or new flags and options to the front end GUI.
A number of responses to these issues have been suggested. U.S. Publication No. 2003/0074636 relates to a method for generating GUIs from Document Type Definition (DTD) files. DTD files are used to express a schema that describes a document or a portion of a document. A DTD file for which a GUI is to be generated is parsed to identify the different elements present in the DTD file. The elements identified are represented in the form of a binary tree-like data structure. The binary tree-like data structure is used at run-time to quickly generate the GUI. The generated GUI may be used by a user to enter data.
U.S. Pat. No. 5,812,851 relates to a method and system for dynamically loading compiler back ends for variable compilation outputs. The system as disclosed includes a generic back end that is capable of interacting with a number of independent back ends that are loaded at run time. The independent back ends create their own back end tree that is adapted to the outputs of the generic back end. The system further includes a front end that produces an abstract syntax tree from an input source code file. The generic back end provides an interface for communication between the front end and each individual back end.
U.S. Publication No. 2005/0010901 relates to method for generating a GUI. A code corresponding to each GUI element is stored. The GUI elements may include text boxes, dropdown boxes, check boxes, radio buttons, etc. When a request from a user system for a specific GUI element is received along with certain parameters, the corresponding code is used to generate a generic version of the GUI element requested. The generic version of the GUI element then is modified based on the parameters passed on by the user system.
The article “Domain Independent Visual XML Editor: Version 1.2”, by Jörg Schummer, Tayyab Zaheer, Wenfeng Liu, Ahmer Iqbal, Jari Kivelä, and Juuso Näsi, relates to a Domain Independent Visual XML Editor. The Domain Independent Visual XML Editor provides functions that XML users may use to generate a GUI directly from the XML schema. In the event that the XML schema is not available, it may be extracted from XML document itself. The Domain Independent Visual XML Editor generates a graphical representation of the XML schema, which is used by a user to interact.
The article “Web-based XML Editing with W3C XML Schema and XSLT” (Source: http://www.xml.com/pub/a/2003/04/30/editing.html), by Ali Mesbah, and the article “Transforming XML Schemas” (Source: http://www.xml.com/pub/a/2003/01/15/transforming-schemas.html), by Eric Gropp, relate to a method for editing a XML instance document through an automatically created form-based GUI, based on the schema of the XML instance document. The schema information is available in a XML Schema Definition (XSD) document. The method as disclosed creates an input field in the GUI corresponding to each element in the XSD document.